I thought the original intent was not only standardization, but also
compatibility! I know I'm new to list and haven't read very much of
the traffic, but I recently saw some sort of suggestion about replacing
the keyboard table! This table is system wide. Replacing it is suicide
for MultiTOS.
It wouldn't be hard to use a dual-lookup system for hot-keys instead.
need, its just a matter
of structuring your application properly. Changing system tables is
a BAD idea.
Also, some keys are reserved by MultiTOS.
All CTRL-ALT-FKEYS, CNTRL-ALT-Z, CNTRL-ALT-C, CNTRL-ALT-\, ALT-TAB, and
to a lesser degree (depending) CNTRL-C, CNTRL-Z, CNTRL-\, CNTRL-ALT-Q, CNTRL-ALT-S, CNTRL-Q, CNTRL-S, and a few other keys (run STTY to see which). Many of
the non CNTRL keys won't affect a GEM app, but CTRL-ALT-C and CTRL-ALT-Z
sometimes will, and CNTRL-ALT-\ always kills the program. I'm not sure what
about the other keys, but to be on the safe side, I'd recommened against
using them.
Someone mentioned VA_START protocol, can someone email me a short note
to refresh my memory about what this does? Also, the new system sends
resolution change messages and you supposed to shut-down your app. I'd
like a standardized safe way to automatically re-start or stay in memory
when the resolution has been changed. Some sort of enhanced libraries
would also be nice - so that the new functions of MultiTOS can be compiled
into a program through a command-line switch (I mean that the standard
library calls would handle the new functions, and these library calls
would call the OS if compiled for MultiTOS and would emulate the call if
compiled for older TOS).
Global shut-down and restart would also be nice to implement, so that a
user can shut-down the system and then after he restarted all his apps would
be reloaded with all the proper data, ready to go, just as he left it.
